\section{Communication}
	\label{sec:communication}
	
	In previous sections design choices have been made such that part of the system runs on the NIOS (namely, the control loop) and part of the system runs on the Gumstix (the actual application). Because the Gumstix should be able to control the rotating wheel, some method of communication needs to be established between the two. There are several possibilities, for example UART, SPI and I$^2$C. However, a discussion between these possibilities is omitted in this report, because UART was the only option. This was because of a voltage difference between the Gumstix and NIOS. The voltage converter that was needed for this was only available for the UART. Thus, in this section we focus on UART communication only.
	
	\subsection{UART}
		A Universal Asynchronous Receiver/Transmitter (UART) is a piece of hardware capable of translating data between parallel and serial forms. It transmits bits one at a time, thus in a sequential fashion. At the destination, the receiving UART receives the individual bits and puts them back together into bytes.
		
		The relevant parameters that have to be explored when using a UART are speed, data bits, parity bit, stop bits. The amount of data bits is usually set to 8, as this is the amount of bits that makes up a byte/character in code. In this way, it is possible to send one byte in each frame, thus this is a good choice. The amount of stop bits determines how well a frame is detected by the receiver. Because modern UARTs are good at detecting this, just 1 stop bit is sufficient. The parity bit can be used for error detection at frame level. It is generally not used, because error detection can also be used at packet level. This leads us to the following parameters for the UART: 8 data bits, 1 stop bit and no parity bits. The amount of characters per second that can be transmitted with these settings is equal to the speed in bits per second divided by ten. After some testing, we found that a speed of 115200 bps was high enough, while still having a very low bit error rate.
		
	\subsection{Protocol}
		\subsubsection{Packet design}
		A protocol has been created which defines the way that messages should be send to each other. When defining a protocol, several things have to be taken into consideration.
		
		\begin{itemize}
			\item Binary representation versus string representation
			\item Error correction, error detection or none of these
			\item Mark of start/end of packet
			\item Acknowledgements or not
		\end{itemize}
		
		Binary representation of a packet is more compact and less resource intensive to parse, but it is generally harder to debug because binary representation is hard to read. A binary representation was chosen, because the NIOS only has limited resources available and thus these needed to be used efficiently.
		
		The communication link is quite reliable even at the speed of 115200 bps. However, there is still a probability that a packet is received in error. Because this could have bad consequences (the wheel could be steered to the wrong position for example), it is neccessary to add some simple error detection. Error correction was considered to be not needed, because it is more resource intensive both for processing power and size of the packet. The error detection that is used is a simple XOR of all packet bytes. The last data byte of each packet consists of the XOR of all previous data bytes. This provides a way for the receiver to check if all bytes are received correctly (with high probability). A more sophisticated checksum could be used, but the XOR was considered to be sufficient for this purpose, because it is easy to implement and is not computationally intensive.
		
		Because packets can differ in size, it is not known beforehand how many bytes need to be received before the packet is complete. But also in the case that packets are all the same size, it is still a good idea to introduce a start and end sequence for the packet. This is, because bytes in the packet could be lost during transmission, which would mess up the receiver state. The byte 0x10 was chosen as starting byte and the byte sequence 0x10 0x03 was chosen as the end of the packet. Because it is also possible that 0x10 occurs in the data part of the packet, these 0x10 bytes need to be escaped by adding another 0x10 in front of it. This leads to the following packet as described in figure \ref{fig:protocol}.
		
		\begin{figure}
			\centering
				\includegraphics[width=1.00\textwidth]{images/protocol.png}
			\caption{The definition of a packet in the protocol}
			\label{fig:protocol}
		\end{figure}
		
		Acknowledgements provide a way to let the sender of message know if his message was received correctly. It is good practice to use them in protocols, because it provides a way for the sender to retransmit the message if it was received in error. Therefore, acknowledegements were added to the protocol.
		
		\subsubsection{List of commands Gumstix to NIOS}
		The following commands were defined for communication from Gumstix to NIOS.
		
		\paragraph{Reset (0x40)}
		The format of the command is shown in table \ref{tab:reset}. The reset command is used to reset the controller to its first state. The NIOS responds with an ACK and starts with the homing procedure.
		\input{tables/reset}
		
		\paragraph{Add to vertical position (0x50)}
		The format of the command is shown in table \ref{tab:vpos}. This command sets the relative position of the vertical setpoint. It adds the value of the setpoint (in radians) to the current vertical setpoint. The NIOS responds with an ACK.
		\input{tables/vposrel}
		
		\paragraph{Add to horizontal position (0x51)}
		The format of the command is shown in table \ref{tab:hpos}. This command sets the relative position of the horizontal setpoint. It adds the value of the setpoint (in radians) to the current horizontal setpoint. The NIOS responds with an ACK.
		\input{tables/hposrel}
		
		\paragraph{Set absolute vertical position (0x52)}
		The format of the command is shown in table \ref{tab:vposabs}. This command sets the absolute position of the vertical setpoint. It sets the value of the vertical setpoint (in radians). The NIOS responds with an ACK.
		\input{tables/vpos}
		
		\paragraph{Set absolute horizontal position (0x53)}
		The format of the command is shown in table \ref{tab:hposabs}. This command sets the absolute position of the horizontal setpoint. It sets the value of the horizontal setpoint (in radians). The NIOS responds with an ACK.
		\input{tables/hpos}
		
		\paragraph{Get position (0x60)}
		The format of the command is shown in table \ref{tab:getpos}. This command gets the current value of both the horizontal and vertical quadrature encoders. This value is not in radians. The NIOS responds with an ACK and a position response (0x60) packet.
		\input{tables/getposition}
		
		\subsubsection{List of commands NIOS to Gumstix}
		The following commands were defined for communication from NIOS to Gumstix. The NIOS only sends a command in response to a command from the Gumstix.
		
		\paragraph{ACK (0x20)}
		The format of the command is shown in table \ref{tab:ack}. An ACK is sent in response to every correctly received packet.
		\input{tables/ack}
		
		\paragraph{NACK malformed packet (0x21)}
		The format of the command is shown in table \ref{tab:nackmalformed}. This command is sent in response to every packet that could not be parsed.
		\input{tables/nackmalformed}
		
		\paragraph{NACK checksum incorrect (0x22)}
		The format of the command is shown in table \ref{tab:nackchecksum}. This command is sent in response to every packet with a non-matching checksum.
		\input{tables/nackchecksum}
		
		\paragraph{Position response (0x60)}
		The format of the command is shown in table \ref{tab:position}. This command is sent in response to the get position packet (0x60) and contains the value of the two quadrature encoders.
		\input{tables/positionresponse}

	\subsection{Implementation}
		Implementation of the protocol is fairly simple. The file \emph{protocol.c} contains the function \emph{parse\_next} which parses the next received byte. These functions are used by both the Gumstix and NIOS. Parsing is done by a simple state machine which only needs the character that was read and the current state. The state machine that was implemented is shown in figure \ref{fig:protocol_state}.
		
		\begin{figure}
	\centering
		\includegraphics[width=1.00\textwidth]{images/protocol_state.png}
	\caption{The state diagram to parse a packet}
	\label{fig:protocol_state}
\end{figure}

		There is also a function which writes a packet to the serial port. This function, \emph{write\_packet}, just writes the start byte followed by the data bytes with all 0x10 values prefixed by another 0x10. It ends with the checksum and the end bytes.
		
		At the NIOS, packets are received and parsed byte by byte. Bytes are only parsed when the control loop is not busy, because it is more important that the control loop runs.
		
	\subsection{Testing}
		All protocol commands were functionally tested and the communication link was also tested for performance. For performance testing, the Gumstix was programmed to send 10 data bytes (thus a total of at least 13 bytes including start, stop and extra 0x10) every 10 ms. The NIOS was programmed to receive these bytes and to calculate the time between reception of the first byte until the time that the whole packet was received, processed and an acknowledgement was sent back. The results are shown in table \ref{tab:serialtest}.
		
		\begin{table}
			\centering
			\caption{Results of performance testing serial port for 10 data bytes}
				\begin{tabular}{c | c}
					  & \textbf{Time (ms)} \\ \hline
				Average & 1.016 \\
				Maximum & 1.269 \\
				Minimum & 0.689 \\
				Standard deviation & 0.086 \\
				\end{tabular}
			\label{tab:serialtest}
		\end{table}
		
		These tests show that the processing time of a packet is minimal. Almost all time is spent in receiving the data bytes, because for 10 bytes, this transmission time already takes almost one millisecond at 115200 bps. Therefore, the performance of the serial communication is good enough to use it in the 10 ms control loop.
		
		%performance
	